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I. 



INTRODUCTION 



At present, most shipboard information handling 
operations are performed manually and are cumbersome and 
often unreliable. Additionally, the manual operations are 
labor consuming to the extent that they pose a threat to the 
Navy's personnel and operational readiness. If personnel 
and operational readiness are to be maintained in a period 
of declining available resources, a more efficient and 
effective means of information handling must be employed. 

The objective of this research was to outline an 
approach to utilize existing automated data processing 
technology in a shipboard environment in an effort to reduce 
the percentage of time shipboard personnel devote to 
repetitive administrative functions. Although specific 
hardware selection was not an intended objective, issues 
ccrcerning hardware and software selection were investigated 
as they related to a shipboard environment. This effort was 
pursued because selection of a particular hardware suit can 
impcse system limitations that can dictate success or 
failure for the system. 

Investigation of shipboard administration functions 
revealed several functions which are likely candidates for 
automation. Differences in ships' size and mission are 
analogous to differences in commercial companies. Each has 
varied functions that are critical in one organization and 
of little ccnsegnence in another. This paper focuses on the 
problems cf automating management functions aboard ships 
with manning levels below 500 personnel. As repeatedly 
emphasised in Ref. 1, a function or system that is not well 
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defined cr is not successfully operating in a manual mode, 
will fail when automated. Keeping this fact in mind while 
concentrating on functions that were extremely time 
consuming, led to selection of the following functions for 
automation consideration: 

1. Shipboard Training and Hecord-Keeping 

2. Maintenance of Personnel Records 

2. Paper Inputs to the Manpower and Personnel 

System (MAPMIS) 

Automating these functions exploits the commonality of 
the data base elements required to support them. This paper 
provides an analysis of the data base requirements and the 
design considerations to successfully generate the 
applications programs that collectively compose the ship’s 
automated management system. 
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II. BACKGROUND 



Several efforts have been made to develop computer-based 
shipboard management systems. These efforts have been 
fragmentary in nature. Results have been isolated 

computer-based packages which do not exploit the extensive 
ccmmcnality cf data base elements that support several 
levels cf nanagement. Additionally, the interfacing with 
higher levels cf command has been ignored in their design. 
As an example, a shipboard personnel record-keeping package 
reguires almost identical data base elements as that of the 
data base utilized by the Bureau of Naval Personnel (EUPERS) . 
A properly designed shipboard data base shculd be capable of 
automated preparation of inputs to the BUPERS data base. 

Related efforts to that of the shipboard computer based 
management system that have beem pursued within the Navy are 
as fellows: 

1. Data Entry Aboard Ship (DEAS) Project 
(CGMNAVSUPS3SC0M) 

2. Development and Maintenance of Continuous Ship 
Maintenance Pro j ect (CSMP) by Minicomputers (CNM) 

3. Data Processing in MLSF Ships. Computer-based system 
supporting supply, 3-M, and administrative functions 

in MLSE ships with Burroughs L3200 system installed 
( COMN A 1 S UP SI SCO M ) 

4. Application cf Shipboard Computers to Instruction 
and Training Administration. (NPRDC) 
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5. Shipboard L-Tran (Lesson Translator). Current 
shipboard CAI for NTDS operators. 

Additionally, the following efforts to automate 
shipboard functions are of particular interest to future 
applicat icns : 



A. APPLICATIONS ABOARD USS DAHLGEEN 



References 2-14 describe effcrts sponsored by the Navy 
Personnel Research and Development Center (NPRDC) to utilize 
a minicomputer tc automate shipboard functions. The 
minicomputer utilized was a commercial version that did not 
meet Military Specif icaticns (MILSPECS) for shipboard 
employment. The system description and applications were as 
fellows: 



1 • Bard ware and Softw are Descri ption 



The system hardware and software avaialable for 
utilization aboard USS Dahlgren consisted of the following: 

CENTRA! EECCESSI NG UNIT (NOVA 1200) 

16 bit wcrd-32K words memory 
memory cycle time-1.2 micro seconds 
physical size-E 10-5* * , W 19*', D 23 * • 
power interrupt protected 
real time clock 

TELETYPE (ASH-33) 

10 characters per second 
paper tape reader and punch 
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CABD R E ABEB 

225 cards per minute 
table tcp mounted 

DISK OBIT 
fixed head 

drive unit (512K words per unit) 
interchangeable disk packs 

LINE PRINTER 

356 lines per minute 
132 columns per line 
table tcp mounted 
OCB-A font 

MAGNETIC TAPE CASSETTE UNITS (6) 

5 tape drives 

CBT REMOTE TERMINALS 
table tcp mounted 
20 lines-60 characters per line 
physical size-H 15”, W 17”, C 27” 

EORTBAN COMPILER 

ALGOL CCMEIIER 

EXTENDEE EASIC INTEBPRETER 

EXTENDEE ASSEMELEB 

EELOCAT A EIE LOADER 

EELCCA TABLE MATH PACKAGE 

BEAL TIME EISC OPERATING SYSTEM (RDOS) 

BEAL TIKE OPERATING SYSTEM (RTOS) 

EISC OPERATING SYSTEM (DOS) 



2 • Applica tio ns 



Two cf the more significant applications applied to 
the NOVA 1200 were the development of a computer assisted 
instruction package to teach shipboard Damage Control and 
the automation of Supply Department functions. 



Reference 13 describes in detail the computer 
assisted instruction effort. The programs were designed to 
rur under the REOS operating system and were written in 
Extended EASIC, version 3.6. The programs were designed as a 
series cf overlays to be operated in a multi-user 
environment and in the swapping mode of BASIC. The system 
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contained an executive program and 19 subprograms capable of 
accessing twc data files: a student data base, and an 
examination statistics file. 

The course of instruction was designed to satisfy 
current Personnel Qualification Standards (PQS) in Eamage 
Control. Instruction was given off-line using textual 
material. Examinations were taken on-line via CRT. Students 
taking an examination were furnished on-line and harc-copy 
test results, diagnostics, and corrective actions for 
improvement . 

The effort to automate the supply functions was 
primarily the result of work done by University of 
Pennsylvania Wharton graduate students. A system titled USS 
Dahlgren Autcmated Logistics Control and Report Generating 
System (LOGCCN) was developed to provide detailed supply 
infcrmaticn in a matter of seconds. LOGCCN consisted of 
eight unique programs. The software documentation fcr all 
the programs is included in Ref. 15. LOGCCN utilized four 
data files: two were random-access disk files and the other 
twc were sequentially accessed tape files. 10GC0N had the 
capability tc prepare supply requisitions, determine if 
stock was available to satisfy a requisition, and tc order 
up the high limit of an item when available stock was at or 
below its specified low level. 

B. A TRAINING MANAGEMENT SYSTEM 

In early 1975 the findings on the Pacific Fleet 
Prcpulsicn Examining Board were that procedures being 
employed within the Engineering Department of USS Kitty 
Hawk(CV-63) for the management of training were ineffective. 
The principal problem being that the cumbersome manual 
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system f cr recording Personnel Qualification Standards (FQS) 
training data proved an inadequate mechanism for the 
Training Cfficer tc effectively supervise and coordinate the 
training. The operational unit commander (Ccmmande r Carrier 
Division Cne) initiated action to investigate automation of 
the traininc function to make it more responsive to the 
several levels of management within the ship. 

1 • System Descri ption 

1 w c computer systems were available for use in 
designing the computer based training management system; the 
iUK 1500 system and a Micro Data 1600 system. The two 
systems were compared in terms of their data processing 
characteristics and user convenience by personnel from the 
Naval Electronics Laboratory Center (NEIC) and the Naval 
Personnel Research and Development Center (NFRDC) . The Micro 
Data system with the addition of a CRT terminal and printer 
was selected for use. The general operating characteristics 
offered by the system were: 

1. Inexpensive terminal installed within the 

Engineering Department 

2. Total time sharing; random access 

3. Individual update capability 

4. Records available on-line at all times 

5. Flexible sorting capability permitting varied 

reporting formats. 
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2 . 



Cat a Base Design Crit eri a 

In designing the elements to be included in the data 
base, the objective was to include sufficient elements to be 
able tc format meaningful training reports tc various levels 
of command while utilizing PQS as the basic vehicle for 
training and assignment of individuals. This design criteria 
was incorporated to make the basic system relocatable for 
use by any cperaticnal units employing PQS. 

The Department Head, Executive Officer, and 
Commanding Officer required summary information to indicate 
the status of training at a given time. Typical data 
elements usee in generating this level of report were: 

1. BQEl-tte number of stations manned during Condition 1 

2. ASGHl-rumber of personnel assigned to a station 
during condition 1 

3. ANQI-number assigned this watch station not PQS 
g ualif ied 

Bepcrts generated for use by the Division Officer 
reguired specific information on individuals tc assess 
previous training, and to determine work assignments. 
Typical data elements utilized to generate this report were: 

1. PQS-the PQS number assigned to the watch station 

2. TRNG-number of personnel in training for the watch 
station 
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3. CEIT-FFE-numh er of watch station personnel with FED 

less than 60 days 

Space supervisors utilized seme of the information 
available in the Division Officers report, but required 
specific information on individuals in their work centers. 
One of the primary considerations in designing the data 
elements was to facilitate alphabetical sorting cf 
individuals when information is desired on a single 
individual. Sample data elements utilized in preparing the 
reports for werk center supervisors are: 

1. NAME-last name of individual 

2. COSEI-watch station assigned for Condition 1 

3. L-EATE-FED or discharge date 



C. EESDIiS 



Althcugh much time and effort was devoted to 
aforementioned systems, very little practical 
resulted from either. The reason for this lack of 
can be attributed to personnel involvement and the 
utilized . 



the two 
benefit 
results 
hardware 



In beth systems, enthusiastic personnel worked on their 
implementation , but failed to get non-computer oriented 
personnel involved in the development. As personnel were 
rotated, lack of system understanding resulted in users 
losing confidence in the systems and returning to manual 
methods cf performing the functions. 



The hardware utilized in both systems was off-the-shelf 
computing equipment. The systems had to be designed to fit 
the capabilities of the existing hardware. Varying underway 
conditions caused system readiness to be unpredictable. 
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Specifically, DAHLGBEN experienced reliability problems with 
the fixed head disk drive units in heavy seas. An automated 
data system that displays marginal reliability is little 
improvement ever manual operations. 
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III. SYSTEM DESIGN CONSIDERATIONS 



A question often asked when discussing automation of 
ncn-tactical shipboard functions is, "Can existing shipboard 
computer systems be utilized?" On many combatant ships 
existing computer systems (e. g. NTDS) are an integral part of 
weapons systems or tactical-support systems. Reference 16 
was a survey made to determine the suitability and 
availability of onboard computers for training and ether 
non-tactical utilizations. The results of the survey were 
that computers installed for tactical purposes were 

hard-wired and not configured for ether purposes and these 
computers were generally not available for other uses when 
the ship was underway. 

The acquisition of any computing system involves 
detailed evaluation of tangible and ether not easily 
measured factors. The comparison of computing systems in 
terms of hardware performance factors such as speed and 
storage capability are straightforward measurements. Cn the 
ether hand, the evaluation of the reputation of a particular 
vendor and the problems of interfacing his equipment with 
that of another vender are abstract considerations that must 
also be taken into account when selecting a system. 
Reference 1 provides a comprehensive checklist for 
utilization in system comparisons. Issues of particular 
interest to the shipboard environment are the following: 

1. Reliability 

2. Physical Planning Consider ations 

3. Mini vs Micro Computer 

4. Software Considerations 
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A. RELIABILITY 



In the selection of most computing systems , cost often 
has been the dominant criteria influencing the selection 
decision. Ic the case of the shipboard system other factors 
must be given greater weight in evaluating systems of 
comparable operating performance. Reliability of the system 
should be a major consideration in selection of any hardware 
suit. Two of the most commonly used criteria to evaluate 
reliability are Mean Time Between Failure (MTBF) and Mean 
Time to Repair (MTTR) . 

References 17 and 18 enumerate the Standard Military 
Specif icaticES that have teen developed for the protection 
of shipboard electrical equipment. Although utilization of 
MIISFECS is required and results in improved reliability, 
the purchaser must be aware of the price he must pay to 
ensure compliance with MILSPECS. 

An example of the cost of complying to MILSPECS can be 
seen by comparing a Data General 830 with a Rolm 1602. 
These two miri-ccm puter systems use the same circuit design 
and software. The Data General 830 is designed to meat 
commercial needs while the Rolm 1602 is a militarized 
version. A comparison of the two systems, each configured 
with the basic computer, 32K core memory, a control panel, a 
power monitor, and an automatic restart capability; revealed 
the Rolm 1602 purchase cost ($48,650) to be mere than double 
that of the Data General 830 ($ 18, 05 0) . Cn the reliability 
side, the Rolm 1602 had a MTBF of 13,200 hours as compared 
to the Data General 830 with a MTBF of 4510 hours. Assuming 
repair parts and technical expertise were available when a 
failure occurred, there was no significant difference in the 
MTTR of the two systems. 
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The above comparisons while rather crude in nature 
highlight a simple fact the purchaser of a shipboard system 
must recognize. It will cost more in dollars to perform an 
automated function afloat than to perform the same function 
at a shore-based activity. This fact must be recognized and 
documented when performing the economic analysis required to 
justify purchase of the system. 

E. PHYSICAL PLANNING CONSIDEEATIONS 



Once the performance design characteristics of the 
system have been established, system location plans must be 
carefully considered before a particular system is selected. 
When commercial systems are procured, system performance is 
given top consideration. Space requirements are secondary in 
nature, usually resulting in space being obtained (purchase 
or rental) tc meet the requirements of the system selected. 
Space aboard most ships in commission in the United States 
Navy is a critical factor. The addition of any electrical 
equipment cften requires removal of some existing equipment 
or the reduction of space allocated to personnel 
habitability. This requires that space requirements be a 
major factor in system selection. At a minimum the 
following factors should be closely examined in determining 
the suitability of a space for installation of a computing 
system : 

1. Overall Sguare Footage 

2. Deck leading Restrictions 

3. Air Conditioning 

4. Humidity Control 

5. Cable Length Requirements 

6. Laycut of Cable Trunks 

7. Voltage Reguirements 

6. Ability to Keep Space Dust Free 
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c. 



MINI *S MICRO COMPUTER 



The functions proposed for automation within this paper 
reguire prompt responses from the computing system to 
warrant automation. They do not, however, reguire the high 
instruction execution speeds available in many present day 
large-scale machines. This fact coupled with the space 
restrictions previously mentioned, reduce the choice to that 
of a mini-computer system or a micro-computer system. 

Price and space reguiremenrs make the use of a 
micro-computer an attractive alternative. Technclcgical 
development cf the micro-computer has been limited only by 
the all important corresponding software development. In 
fact, many authors have pointed out that the introduction of 
the micro-computer has put software development for these 
devices tack at the point where software was for 
macro-computers in the early 1950's. Until software 
development for micro-computers catches up tc the 
technological hardware developments, a mini-computer is the 
cnly logical choice for use in automating shipboard 
administrative functions. 



D. SOFTiABE CCNSIIERATIONS 



There exist many issues in implementing a data 
processing system on a mini-computer. To properly exploit 
the strengths and weaknesses of the mini-computer several 
software issues as they apply to various applications must 
be resolved. Reference 15 addresses many of the issues 
including the following: 
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1. Program Complexity 

2. Storage Utilization 

3. Operating System Complexity 

4. - Extent of Documentation 

5. Assembly vs High Level Language 

1 • |rcc[ram Cc m plexi ty 

+ 

In many applications the knowledge of what gees on 
within a program is of little consequence to the user. When 
a programmer writes a progam for his own use he may violate 
as many of tie principles of good programming as he chooses. 
In general though there exists a trade-off between 
programmer care and user skill. The term "user" as applied 
to the shipboard environment ranges from the Data Processing 
Technician (DP) , who will be responsible for maintaining 
certain programs, to the Seaman who will be expected to 
operate an cr-line terminal as part of the training system. 

The varied intelligence and backgrounds of the 
shipboard users is such that the programs written must 
display a high degree of "intelligence" . The cues for 
interaction must be precise and simple. The programs must 
give concise error messages notifying the user when he has 
supplied unacceptable or impossible data. Programs that may 
reguire future shipboard modification must invoke simple, 
well documented logic to account for the inexperienced DPs. 
The trade-o-ff for this action is larger, less efficient 
programs. In the commercial environment mere emphasis is 
placed on the efficient use of the limited memory normally 

associated with a mini-computer system. In the shipboard 

environment the success of the system will depend upon the 

degree of usage by a cross section of the shipboard 

personnel. Usage in turn can be directly linked to 
simplicity of operation. 
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2. Storage Dt il ization 

Although the price of core memory has been 
drastically reduced within the past ten years, it still 
represents a substantial enough investment to influence 
overall system design. Most common mini-computer 
configurations offer 32K or 64K of core memory per 
processor. There exists several popular schemes available 
for managing the available memory ranging from the simplest 
of allowing one user full access of core to sophisticated 
paging systems. The best scheme for utilization of memory is 
basically a factor of average program size and the number of 
anticipated users. 

The shipboard system requires a time sharing 
environment to support multiple users. Again space 
limitations restrict the number of users. In the case of a 
Destroyer size ship, available space may only allow for 
installation of as little as four on-line terminals. In this 
situation partitioning memory into static partitions of 8K 
each or incorporating a simple swapping algorithm should 
yield satisfactory results. The trade-off to be recognized 
in partitioning the memory is that of restricting program 
size. The situation that must he avoided is one in which 
program size dictates programmers writing sophisticated 
programs at the expense of program clarity and simplicity of 
utilization . 
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3. Operating S yst em Complexity 

Here again the trade-off is one cf convenience vs 
core utilization, host mini-computer manuf ac turers offer one 
or mere operating systems for their particular machines. 
Before deciding on a system with more than one operating 
system, the purchaser should require a demonstration or the 
degree of difficulty and time required to exchange the 
operating system residing in core with one from a mass 
storage device. 

The limited number of simultaneous users in the 
shipboard environment dictates a rather simple minded 
operating system. Often a manufacturer will try to sell the 
most sophisticated operating system developed for his 
machine. It may prove worth-while to consider building an 
operating system designed specifically to match the desired 
requirements cf that particular installation. The points to 
keep in mind in making the decision are that too complex an 
operating system will overburden core and that the more 
sophisticated the operating system the greater the 
probability cf it containing holes or errors not previously 
encountered . 

4 . Extent of Co c umentat ion 

Every programmer is continually reminded of the 
value cf program documentation. In the mini-computer 
environment, while the value of documentation can net be 
overlooked, one must recognize that trade-offs exist. It is 
a true consequence that source program documentation causes 
programs to be larger and take up more space. In the case of 
the EASIC language, which is interpretive, the whole source 
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program is put into core at run-time, and source statements 
are interpreted as they are sequentially executed. Thus 
blank cards inserted for spacing consume space within core. 

If the source language of a program may be compiled 
or assembled and gotten into core image form, internal 
documentation will not affect the size of the loaded program 
at run-time, a compromise that exists is tc store the source 
program on magnetic tape and store the core images of 
frequently run programs on disk. Another alternative is to 
have two versions of a program; one fully documented and 
stored cn magnetic tape and the other with no documentation 
avaiable cn disk. 



5. Assemb ly vs H iqh Level Langu age 



Another trade-off that must be considered is the use 
of assembly language to save core and disk space or the use 
of a high level language for ease of programming and program 
maintenance. The Data Processing Technicians who will be 
assigned aboard ship will generally possess little 
background in working with assembly language. In most 
instances the Data Processing Technicians will only be 
familiar with CMS-2, used on Navy tactical systems, or 
COECL. These programs where maintenance is anticipated or 
unigueness is not desired should be written in a high level 
language. The operating system and training programs where 
standardization among ships of a class is the desired 
objective should be coded in assembly language. 



The choice of the high level language to be utilized 
in the applications programs is greatly influenced by the 
hardware selection and the amount of core purchased. While 
it would be desireable to write the programs in COBOL due to 
its familiarity among Navy DPs, it is not presently a 
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practical alternative. The cere requirements of available 
CCEOL compilers have resticted implementation of COEOL in 
the mini-computer environment. The development of a new 
high level language incurs a high initial cost. Some 
currently available popular mini-computer languages and 
their descriptions are as follows: 

a. FOCAL 

FOCAL is a simple programming language which was 
designed for implementation on the DEC PDP-8. FOCAL is non 
block structured. Variables are not declared in FOCAL. 
Storage is allocated for a variable after the first 
occurrence of a SET command. Array elements are allocated 
cne at a time when they are first referenced in the program. 
FOCAL supports the standard arithmetic operators, but 
relational operators are not implemented. Program control 
is provided by the IF, GO, GOTO, DO, RETURN, and FOR 
statements. I/C is not very sophisticated in FOCAL. The I/O 
commands are ASK and TYPE. FOCAL provides quite a number of 
built in functions (i. e. trigometric) and has the facility to 
let the user define his own functions. Although FOCAL is 
easily learned, it is machine oriented and bcund to the PDP. 
Its usefulness in simple program application is offset by 
its lack cf power and transportability. 

b. EI-11 



PL-11 is a block structured language which was 
created for use on the DEC PDP-11. PL-11 constructs are good 
for writing readable, structured programs. All variables and 
procedures in PL-11 must be declared. The Bit data type 
allows the user to reference individual bits in main memory 
through use cf the SET and CLEAR commands. PL-11 offers the 
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standard arithmetic and logical operators. Iterative control 
within a program is effected through use of a standard type 
of looping. Nesting of procedures to any desired level is 
permitted and recursive calls are allowed. By declaring a 
variable to be of type STACK the programmer may make use of 
the POSH and POP functions which serve to manipulate the 
top-of-stack element. PL-11 functions make special use of 
PDP-11 hardware features and is thus non-transportabl e . 

c. C 

C is a compiler that was first developed on a 
PDP-11 anc used to implement the UNIX operating system. C is 
neither block structured nor based on a commonly used high 
level laguace. C supports the standard arithmetic and 
relational operators and in addition some unusual operators 
influenced by the hardware of the PDP-11. Program control is 
accomplished through use of the IF, WHILE, FOR, DC, and 
SWITCH statements. The SWITCH statement is equivalent to 
the traditional "CASE" statement. Functions in C may be 
recursively called. Formatted I/O is accomplished through 
library routines which convert decimal, octal, and floating 
point values to or from ASCII. As with the two previously 
mentioned languages, C is highly machine dependent. 

d. ECRTRAN IV 

Many mini-computers make use of powerful FORTRAN 
compilers. Using a standard operating system implemented in 
assembler code, they provide the capability for supporting a 
powerful E GEIfiAN which is compatible with IBM's level G 
compiler. Utilizing an INLINE statement they allow inclusion 
of assembler code between FORTRAN statements providing 
greater programmer flexibility. The drawback of these 
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compilers , as with all FOBTBAN compilers, is the difficulty 
encountered in utilizing them in non-numer ical applications. 



e. EASIC 

The programming simplicity of EASIC has made it 
one of the mcst popular mini-computer languages. The editor, 
file storage, and program execution are combined into a 
single system allowing BASIC to be independent of any 
operating system. The Dartmouth standard EASIC includes more 
powerful constructs than it's FOBTBAN IV counterpart by 
supporting string manipulations, matrix operations, 
formatted I/O, external subroutines and a file system. 
Additionally, EASIC programs execute interpretively which 
circumvents problems of compilation caused by limited 
memory. With suitable extensions, BASIC can be used for a 
variety cf sophisticated and demanding applications. A 
EASIC programmer does not manage main memory directly. 
Instead, he manages program space which consists of numbered 
instructions and variables both of which require space in 
main memory. When EASIC programs become too large tc fit 
main memory, the programs must be broken into overlay 
modules with inter-module sequencing logic. Beference 9 
presents a structuring and design strategy for managing 
overlays . 



Weighing equally the factors cf programmmers 
ability, machine independence, and power of the language, an 
extended version of EASIC becomes an attractive choice of a 
high level language for use in the shipboard management 
system . 
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IV. INTERFACE WITH MAPJIS 



A high percentage of shipboard administration time is 
dedicated tc generation, verification, and correction of 
inputs tc the Navy's Manpower and Personnel Management 
Information System (MAP MIS) . Presently, source data is 
entered into the MAPMIS data base as a result of internal 
Supers fuicticns as well as world-wide field data reporting. 
The present reporting process is error prone resulting in a 
significant rate of errors being introduced into the data 
base. This situation has resulted in many costly, faulty 
decisions by the users of the data base(i.e. detailing an 
individual tc fill a billet that was previously filled, but 
net recorded in the data base) . 

The nature of errors in the data base can be the result 
of several circumstances. Errors attributed to lack of 
timeliness can occur if decisions are made on a data base 
that dees not reflect the most recent personnel 
transactions. The most common errors are inaccurately 
reported information or the failure to repert information 
reguired tc update the data base. The worst situation 
develops when faulty information that has been entered into 
the data base is used to edit inputs, resulting in rejection 
of entirely correct information. 

The present method utilized to handle errors is to 
research them at the point of detection, usually Supers, and 
if possible correct them and re-attempt to update the data 
base. This method of error research is manpower- int ensive 
and even with the significant resources presently available, 
resolution is freguently not attainable, causing an 
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accumulation of backlogs. Often, reports must be returned to 
the ships and shore stations originating them. When this 
situation arises, errors associated with timeliness may 
result. 

Bupers has undertaken a source data improvement program 
to identify areas in which accuracy and timeliness can be 
improved. The short range plan utilizes existing structures 
for reporting. The current OCR reporting formats and the 
Diary system will be maintained. What will change is the 
method by which the data is transmitted, verified, and 
entered into the MAPMIS data base. 



A. REPORTING STRUCTURE 



Under the MAPMIS system, there will exist five basic 
nodes or reporting levels in the system. They are in the 
order of their data processing capability: 

1. Central Processing Node 

2. A. E. S. 

3. High level Terminal (HIT) 

4. low level Terminal (LIT) 

5. Remote Unit 

The central processing node will be the MAPMIS itself. 
The A. D. S. activities are those with large existing 
personnel data bases such as the Chief of Naval Education 
and Training (CNET) . Ships reporting their local 
transactions will not be concerned with these activities. 
The lowest reporting node will be a separated unit incapable 
of supporting a low level terminal. An example of such a 
unit might be a motil medical team attached to a Karine 
Corps unit. A ship configured with a mini-computer would be 
considered a low level terminal activity reporting personnel 
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information to the MAPMIS through a high level terminal 
activity . 

A high level terminal activity is characterized by the 
maintenance of a local data base kept in synchronization 
with the Supers data base. This concept is dependent upon 
the concept of a centralized base personnel office. As an 
example, instead of every Navy activity in the geographical 
location of San Diego manning its own personnel office, a 
central base personnel office will maintain a local data 
base cn the order of 10,000 officer and enlisted personnel. 

The HIT will be supported by a mini-computer with 
sufficient disk capacity to maintain the local data base. 
The mini-computer will be capable of intelligent terminal 
processing of a large variety of data input formats. The 
high level terminal activity will support remote data 
stations via a hard-wired arrangement or through use of a 
modem and a telephone data set. The HIT processor will 
provide operators at remote data stations with error 
analysis such as syntax, formating errors, or validation 
errors against the local data base. 

The data in the data base will be a slave of the central 
data base of MAPMIS and kept in synchronization through a 
feedback transmission scheme. All HLTs will be identical in 
operation except for the number of personnel within each 
local data base. 

In general, a low level terminal activity (LIT) is 
characterized by its inability to maintain a local data 
base. Although a ship configured with a mini-computer surely 
has the capacity to maintain a local personnel data base, 
its lack cf telecommunications capability while underway 
prohibits synchronization of its data base with that cf the 
MAPMIS. Therefore it will be classified as a LLT as will 
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ships having nc local data processing capability; configured 
only with a simple low level terminal. The output of an LLT 
will be transactions recorded on bulk media such as data 
tape cassettes or floppy disks that will be forwarded tc an 
HIT for input into the system. When underway a ship would 
utilize this approach. While inport, the ship would be tied 
to the HIT via modem and telephone data set. 



B. DATA IB A K EMISSION 

The greatest density of data flow will occur between the 
HLTs and the central processing facility. Periodically the 
HIls will transmit all transactions that have accumulated to 
that time. The central processing facility will in turn pass 
a feedback transmission for the purpose of validation. 

A significant amount of data transmission will occur 
within the HIT itself. Personnel clerks at user activities 
will prepare rough worksheets in OCR or Diary formats. When 
entering the data in the HLT data base, they will select the 
report type by depressing a function key. The system will go 
into the correct mode for receiving the data for that report 
and provide cues for entering it. As the operator enters 
data, static information will be provided tc cross check the 
data. As an example, if a man’s social security number is 
entered, the system will feed back the man's name. The 
operator can then tell if he has entered the social security 
number ccrrectly and if he is processing information on the 
desired individual. 

The Iccal processor edits the incoming data checking it 
for correct format and syntax. As an example, when age is 
called fcr, the processor may only allow numbers between 17 
and 45 to he entered . When the report is completed the 
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information contained in it is ccmpared to the local data 
base to ensure that it is consistant with infomation 
already contained within the data base. 

An additional feature of the HLT will be the ability to 
prepare formal documents that require a signature. These 
documents will be prepared on the local line printer and 
forwarded tc the cognizant command for signature. Services 
such as preparation of personnel rosters or personnel 
"tickler" actions will also be available upon request. 

When a ship gets underway, it shifts from a remote HLT 
user to a III. In this situation a significantly different 
approach will be taken to data entry. The personnel clerk 
will still prepare the data in rough OCR or Diary format. 
The processing difference occurs in the level of editing. 
The ship will possess no personnel local data base acainst 
which tc check the input data. Data that is entered will 
only be checked for logical correctness such as format and 
syntax. If the data passes the low level editing, it will be 
output on cassette. At first opportunity the cassette will 
be forwarded by courier or postal servive to the specified 
HLI for entry into the local data base. 

If upon arrival at a HLT, transactions do not pass the 
editing requirements cf the HIT, an attempt will be made to 
locally correct the transaction. If the correction cannot be 
effected at the HLT, a feedback transaction will be prepared 
and returned to the LIT to rectify the error. 
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c. 



PRIVACY CONSIDERATIONS 



The introduction of several local data bases requires 
that the standards of personal privacy as set forth in the 
Privacy Act cf 1914 be applied. The local data bases are 
part of a reporting system and no decisions concerning 
individuals will be made based on the data contained in 
them. Additionally/ no disclosures will be made from data in 
the data bases. The data in the local data bases will 
subscribe tc the standards of "routine use" as set forth in 
the Privacy Act. 
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V. 



AOTGMATED TRAINING 



The task of accomplishing the reguired training 
necessary tc insure a ship's combat readiness takes a high 
percentage cf the Navy's manpower and fiscal resources. The 
moving cf shipboard personnel to f and maintaining them at 
shore based schools is a costly reguirement. This 
reguirement exists due to the complex technology 
incorporated in the training and the lack of sufficient 
instruct icnal personnel to carry out the training at local 
command s . 

The training that is carried out at the shipboard level 
is most often administered tc groups, of individuals. The 
effectiveness of this training method depends upon the 
competence and teaching skills of the instructor and the 
comprehension level of the personnel receiving the training. 
The method dees not allow for differences in learning 
abilities of those individuals receiving the training. 
Additionally, the effectiveness of the individual 
instructors is difficult to measure. 

The use of the computer in administering shipboard 
training offers the following benefits: 

1. Complex Training at Shipboard Level 

2. Standardization of Training 

2. Individuals Taught at Their Own Face 

4. Reduced Training Costs 

5. Instant Indi vidual/Ccmmand Training Status 
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A. DEGB £ E CF AUTOMATION 



Two methods of utilizing a computer to assist in the 
training effort were investigated. They were: 

1. Computer Assisted Instruct ion (CAI) 

2. Computer Integrated Instruction (CII) 

Computer assisted instruction has become an increasingly 
popular vehicle to train military personnel at shore based 
activities. CAI instruction is administered predominantly 
on-line. Under this method of instruction a student receives 
the basic lessen via a CRT terminal, takes his examinations 
on-line, and receives diagnostics and prescrip tives also 
administered via the CRT. 

Computer integrated instruction is a method in which 
basic instruction is accomplished off-line via printed 
materials. Testing, diagnostics, and prescript ives are 
received on-line. The off-line training consists of 
programmed instruction (PI) , audiovisual instruction (A/V) , 
and self study guides (SSG). 

Educators generally favor the CAI method because it 
holds the individual's attention while leading him from 
lesson through examination. The drawbacks of this methed are 
that programs tend to be extremely large due to the reguired 
verbosity cf the lesson. The limited memory of a 
mini-computer system makes this an undesirable program 
characteristic. CAI requires that an individual spend long 
periods at the CRT terminal. This situation could cause 
contention for terminal time on ships capable of maintaining 
a limited number of terminals due to space restrictions. 
The CII method, however, requires an extremely simple 
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insructicn set for the user. The system can be implemented 
with as little as three user commands. These commands should 
allow the user to check his training status, call a shopping 
list of available examinations, and select the desired 
examina ticn . 



E. SYSTEE CEEBATICN 

The basic support materials for the CII will be prepared 
by the Naval Training Command. Specific subject areas will 
be broken into several modules. The normal sequence of 
instruction for each module is: 

1. Take a pre-test on the computer 

2. Take the module lesson off-line 

3. Take a post- test on the computer 

The pre-test is used to measure existing knowledge of 
the material presented in a particular module. Passage cf a 
pre-test demonstrates proficiency in the material presented 
in the nodule and the qualification will be entered on the 
individuals training record. If the pre-test is failed, 
specific lessens will be presented on the CBT and a 
hard-copy furnished via the printer. Upcn completion of the 
prescribed material, a post-test will be taken on-line. If 
the pest test is failed the individual is directed tc retake 
the prescribed lessons for the module. Figure-1 illustrates 
the procedural flew cf the system. 
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FIGURE 1 - PROCEDURAL FLOW 
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C. PILE EECCIBEMEN'IS 



The computer integrated instruction can te supported in 
its simplest form by two data files: a student data base and 
an examination data hase. The student data base will contain 
general information on the student for identification and 
will record bis training status for the various training 
subjects he is undertaking. Information to be included in 
the student data base is module status pre-test and 
post- test results, and start/comple tion dates. Figure-2 
represents the flew of information in the system. The 
student data base will be maintained on magnetic tape and 
leaded tc disk at the beginning of a training period. The 
tape will te updated at the end of the last training period 
of the day. 

The examination data base will consist of a separate 
physical file for each pre-test and post-test. A relatively 
inexpensive method of maintaining these files is on cassette 
tapes. The cassette files will be loaded to disk upon 
reguest cf the individual user. These files will rot be 
modified by shipboard personnel. 
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FIGURE - 2 INFORMATION FLOW 
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c. 



DATA ELEMENTS 



The training modules should be structured to satisfy PQS 
requirements for those particular subject areas where PQS 
has been i np lement ed. The information in the student data 
base should be a complete record of the PQS program and the 
status of each individual aboard the ship. The simplest 
method of constructing the file is to design it as a 
variable length file composed of logical records, cne per 
person. The number of physical records composing each 
logical record will be a function of the degree of training 
reguired for the individual associated with that logical 
record. The student data base should contain these minimum 
data elements: 

1. Name 

2. Social Security Number 

3. Work Center 

4. Modules Bequired 

5. Modules Completed 

6. Modules in Progress 

7. Module Start Dates 

8. Module Completion Dates 

S. Test Score Results 

Additional data elements can be added if desired by the 
Command. This will affect the number of physical records 
reguired and the tctal length of each logical record. 
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VI. P ER SONNEL RE CORD S 



The interlace with 3APMIS outlined in Chapter IV is 
totally dependent upon conversion to the Central-Ease 
Personnel Office concept. Should this concept be rejected or 
postponed, ships with data processing capabilities should 
maintain a local personnel data base. The data elements 
contained in the data base should match these required on 
the various paper inputs now being submitted as entry data 
to iJAPMIS. 

Reference 4 offers a simple but effective scheme for 
managing a generalized personnel data base. 



A. SYSTEE DESCRIPTION 

The proposed system requires a data base and a 
dictionary that defines the data in the data base. The 
dictionary is a file containing specific descriptions of the 
data base elements. The dictionary file contains the 
identification, characteristics, and storage locations of 
each data element and is dynamically accessed by I/O 
commands. A dictionary manager program is required to allow 
the user to add, change, and delete records and to print the 
contents of the dictionary. A file manager program is 
required to allow the user to generate report headers and to 
query the data base. 

The tasic design philosophy is structured for a main 
data base and data subsets. The subsets provide multi-level 
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query by a series of selective reductions. The subsets are 
created from the main data base in response to a SELECT 
command. Each subsequent subset is formed by an additional 
SELECT commend operating on the most recently created 
subset . 

Subsets are selected based upon the parameter input by 
the user, e.g., age or name. As an example of the subset 
reduction process, assume the data base contained only the 
following information: 

Name: J. Ercwn, Bate: BM1 

Name: B. Jones, Bate: BM2 

Name: A. Smith, Bate: BM 1 

Name: E. Smith, Bate: BM 2 

Using the SELECT command with the parameter name Smith 
would cause tfce subset of the last two records to be formed. 
Beusing the SELECT command with the parameter rate BM2 would 
form a subset of the last record only. Figure-3 shews the 
system flew for the query process. 

B. USEE CCN HANDS 

The extent of the command set made available to the user 
should again be primarily influenced by simplicity of use. 
It should allow the user as a minimum to carry out the 
following functions: 

1. Add records to the data base 

2. Modify existing records 

3. Delete records 

4. Scrt records 

5. Format printed reports 

6. Display records on the CRT 
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SEARCH 



FIGURE 3 - SYSTEM FLOW 



A command missing from many systems that should be 
included is an ’'EXPLANATORY” command. This command should 
provide an inexperienced user a concise, easily understood 
explanation cf each user command available on the system. 
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VII. CONCLUSIONS 



An automated shipboard command management and readiness 
information system is needed. The basic subsystems tc be 
included are limited primarily by computer capacity and the 
extent tc which they can time-share the system. A basic 
factor is commonality of data base elements to support 
specific subsystems. 

The training and administration function is the 
fcundaticn for assessing operational readiness status of 
individual crew members, teams, and the entire ship. This 
subsystem must provide both training deficiencies and 
training attainment data in the context of ship-specific 
requirements . It should inccrporate the Personnel 
Qualification Standards concept and ether requirements 
established by training directives. Output should include 
reguired training information from the ship to higher levels 
of command. The subsystem will enable commands to select 
which crew members and knowledge/skill areas should be 
trained aboard ship or at training centers ashore. 

In designing any bar dware/sef tware system, there are a 
number cf crucial guest ions to which the system designer 
must find answers. One of the most important in a shipboard 
application is the role of the human operator in the 
operation of the system. The nan-machine interface must 
account for the limited computer exposure cf most shipboard 
persenne 1 . 

Cost effectiveness will be enhanced by maximum use of 
the system and careful choice of functions tc be automated. 
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Simplicity cf use will encourage users. Design 
considerations that involve trade-offs between simplicity 
and efficiency should be weighted to favor simplicity. 

Future developments in micro-computer software should be 
carefully examined before actual implementation of a system. 
As software becomes available to simplify routine data 
processing operations, the advantages offered by the 
micro-computer in the areas cf cost and size will strongly 
favor its usage. 

Hany additional subsystems exist as candidates for 
automation such as payroll, supply, and PUS accomplishments. 
Automation of these subsystems should only be attempted 
after the training and administration subsystems are running 
smoothly. Such new projects must be carefully examined to 
determine tleir contention fcr system resources. 
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